LWN Articles on Kernel: TCP, 6.1, and Bugzilla
-
Fingerprinting systems with TCP source-port selection [LWN.net]
Back in May 2022, a mysterious set of patches titled insufficient TCP source port randomness crossed the mailing lists and was subsequently merged (at -rc6) into the 5.18 kernel. Little information was available at the time about why significant changes to the networking stack needed to be made so late in the development cycle. That situation has finally changed with the publication of this paper by Moshe Kol, Amit Klein, and Yossi Gilad. It seems that the way the kernel chose port numbers for outgoing network connections made it possible to uniquely fingerprint users.
[...]
Kol and company were able to come up with an interesting attack on this algorithm. A hostile web page (otherwise known as almost any page on today's Internet) could load a JavaScript fragment that, through a series of iterations, creates a mapping between destination port numbers and the counter-table entries used to assign source-port numbers. It is, in other words. looking for hash-table collisions on the counter table. This table, remember, has only 256 entries, so hash collisions will not be rare or hard to find.
Specifically, the attack initiates a series of outgoing connections, all to the same remote address, but each to a different destination port. It then looks at the assigned source-port number for each connection attempt (note that the connection need not actually be established). Since any given counter-table entry is incremented after being used to generate a source-port number, two connection attempts that hit that counter-table entry will result in source-port numbers that differ by one — if the source and destination addresses are the same. So the attack looks for connection attempts that resulted in sequential source-port numbers and concludes that the destination-port numbers used in those attempts map to the same counter-table entry.
The optimal number of outgoing connections for one iteration of this attack is said to be one less than the size of the counter table, or 255. A single iteration of this algorithm will produce at most a small number of collisions, which do not tell an attacker much, but it can be run over and over again to come up with more of them. So the above process is repeated until collisions have been found for each entry in the counter table. Once that is done, a second phase uses a similar technique, but mixing connections to a loopback address with connections to the remote-server destination ports found in the first phase. The purpose here is to find which destination ports, when used with a loopback destination, map to the same table cell as one of those remote-server port pairs. This second phase generates pairs of destination port numbers that, when used with the loopback address, generate collisions in the counter table; these port-number pairs are independent of any remote address.
Each pair of colliding loopback port numbers, in effect, tells the attacker a little more about the secret key that the kernel generated at boot time. The key itself is never disclosed, but there is no need for that; a sufficient number of colliding port-number pairs is sufficient to uniquely identify the system involved. The key point is that these port-number pairs are a function of the secret key — which is different for every system — and can thus be used to create a unique device identifier.
-
The first half of the 6.1 merge window [LWN.net]
The 6.1 merge window is well underway: since it opened, 5,752 non-merge changesets have been pulled into the mainline repository. That is approximately half of the work that had piled up in linux-next and marks a good time to look at what has been merged so far. Some long-awaited core changes have landed for the next kernel release, but there are likely to be more significant changes to come.
-
A plan for the kernel Bugzilla [LWN.net]
The kernel's Bugzilla instance is largely unloved and ignored, at least as a bug-reporting tool for the bulk of the upstream kernel. At the recent Maintainers Summit, Bugzilla was discussed during the regression-handling session led by Thorsten Leemhuis. In a followup to that discussion, Leemhuis posted some ideas for improving the state of bugzilla.kernel.org to the ksummit-discuss mailing list recently; the resulting discussion helped clarify a number of problem areas for it—and for the Bugzilla tool itself.
In his post, Leemhuis noted that those present at the summit expressed a fair amount of dissatisfaction with the kernel Bugzilla, so his goal was to propose a few different fixes to make things better. The main complaints during that session were effectively that bug reports via email work better for most kernel developers; there was also concern expressed that the Bugzilla project is unmaintained at this point. Part of his Kernel Summit session (YouTube video) on regression tracking was another place where many of the same problems with Bugzilla were raised. But there are kernel developers (and kernel subsystems) that use and rely on Bugzilla, so the ultimate "solution"—dropping the bug-reporting tool—is not really a viable option even though it is a popular sentiment.
Leemhuis's suggested path is to make it clear that most of the kernel does not use or pay attention to what gets submitted to Bugzilla. There are only 20 of around 2500 entries in the kernel MAINTAINERS file that specify Bugzilla as the place to post bugs; the rest either point to email addresses for mailing lists and maintainers, or to external bug trackers. Part of the problem from the user side is that there are "lots of bug and regression reports (even good ones!)" that never get a reply from a developer, as his analysis back in April showed. His goal is to redirect most of these reports to the proper places, or at least to make it clear to reporters that their bug may well be ignored.